iT邦幫忙

clean code相關文章
共有 26 則文章
鐵人賽 Software Development DAY 3

技術 【Day-3】Clean Code(上)

文章同步於blog 前言 第三天就要來個硬的 這次將要介紹Clean Code 之後會依序介紹Clean Coder以及Clean Architecture C...

鐵人賽 Software Development DAY 2

技術 【Day-2】Coding Style

文章同步於Blog 前言 今天我們會來介紹什麼是Coding Style,以及團隊的Coding Style為什麼應該統一 The Zen of Python...

鐵人賽 自我挑戰組 DAY 1

技術 Day 1 - 為什麼要當Clean Coder跟寫測試

身為一位軟體工程師應該蠻常會遇到一件事,就是需要靠通靈才能知道這支程式到底在說什麼,如果今天有個靈媒證照,那或許我們都可以去試試看,當作副業創造金流好像也不錯(...

技術 如何提高程式碼的可測試性 (Testability)

眾所皆知,寫單元測試有非常多好處,但有些主管會問,為什麼寫測試會讓工程師額外花這麼多時間?除了因為缺乏單元測試技術知識外,根本原因是產品程式碼的可測試性太低,導...

技術 Java Jackson ObjectMapper 教學與注意事項

Jackson ObjectMapper 是 Java 中應用非常廣泛的序列化、反序列化的工具,它可以幫助我們簡單、快速將 Java 物件與 json 之間作轉...

技術 Java SimpleDateFormat 教學與錯誤用法

開發 Java 專案時經常操作時間、日期與字串的互相轉換,最常見簡單的方式是使用 SimpleDateFormat,想必大家對它不陌生。雖然它簡單易用,如果沒有...

技術 多此一舉! 不要這樣用 Java 8 Optional

Java 8 新加入了 Optional 類別,能省去繁瑣的 null check 流程,豐富的 API 也讓程式邏輯看起來更簡潔、易讀。但我卻看到了不少錯誤的...

技術 軟體設計原則 DRY (Don't repeat yourself)

DRY (Don't repeat yourself),是敏捷開發的核心設計原則之一。DRY 原則規定,對於每個知識點,系統中都只有一個明確而權威的表示。這個原...

技術 軟體設計原則 YAGNI (You aren't gonna need it!)

YAGNI (You aren't gonna need it!),是敏捷開發的核心設計原則之一。此原則指出,程式開發者應該在面臨確鑿的需求時,才實作相應的功能...

技術 分析 Spring 的依賴注入模式

依賴注入 (Dependency Injection, DI) 是 Spring 實現控制反轉概念的重要手段。Spring 提供了數種 DI patterns,...

技術 常見的 Java Interface 錯誤用法

在 Java 專案中,應該不少人看過或寫過只有一個實作(implementation)的介面 (interface),並且以 interface-impl 的風...

技術 不建議使用 PowerMock 的理由

寫單元測試時常會使用 mocking framework,因為它能幫助我們輕鬆建立 mocked object,不必再為了單元測試而寫假物件,更容易對待測物件隔...

鐵人賽 Modern Web DAY 29

技術 Day29-寫出更好的 JavaScript 程式碼(下)

前言 此篇將繼續接續上篇,介紹一些寫 JS 的技巧。 語法部分 in operator in 運算子可以用來確認一個物件是否有某個屬性。 const pers...

鐵人賽 Software Development DAY 3

技術 Day 3:何謂Clean Code?

不知道看這篇文章的人有沒有想過,一個遊戲引擎的程式碼是怎麼讓我們這些使用引擎的程式也能理解怎麼使用它們的引擎?更進階的話,他們是怎麼維持有一百萬以上的程式碼運作...

鐵人賽 Software Development DAY 2

技術 無瑕的程式碼

根本難題:品質與截止期限 程式設計的領域中,總是會遇到工期的壓縮,許多時候我們並沒有時間來一場工程師的浪漫,反覆斟酌程式的品質。可是若真屈服於時程而放棄品質,那...

鐵人賽 Software Development DAY 1

技術 書作者序與我的序

緣起 每半年我都想學一樣新的技術或語言,但半個月前在尋找選項時,卻忽然感到了迷惘。新技術迭代地如此迅速,我不可能跟上每一項酷東西,更何況再過一、兩年,或許原本看...

鐵人賽 Modern Web DAY 28
Javascript 從寫對到寫好 系列 第 28

技術 Day 28 - Clean Coder 時程與承諾

前言 今天會接續著昨天的主題,來聊聊 The Clean Coder 的另一個主題。 在我過去的工作經驗中,寫過的程式性質各有不同,有充滿前端互動UI邏輯的(著...

鐵人賽 Modern Web DAY 27
Javascript 從寫對到寫好 系列 第 27

技術 Day 27 - Clean Coder 時間管理與專業人士

前言 昨天講 Clean Code,雖然昨天只聚焦在命名與註解,僅佔 Clean Code 這本書的冰山一角,不過也算是可以一窺什麼叫做「更好的程式碼」,有興趣...

鐵人賽 Modern Web DAY 26
Javascript 從寫對到寫好 系列 第 26

技術 Day 26 - Clean Code 邁向更好讀、好維護的程式

前言 今天的主題會參考這本非常有名的書 Clean Code。 寫程式到最後,除了最基本的,商業功能要能正常運作以外,其實大部分的時候都是在追求,如何讓 cod...

鐵人賽 Software Development DAY 8

技術 Day 08: 【結語】程式碼的氣味和啟發

「這個手環就像是為我的職業道德做出了公開聲明。它是一個明顯的指示,代表我承諾 『我將盡己所能把程式寫到最好』。所以它仍在我的手腕上,當我寫程式時,不斷提醒著...

鐵人賽 Software Development DAY 7

技術 Day 07: 類別、系統、羽化

「在函式裡,我們計算程式行數,來衡量函式的大小;在類別裡,我們使用不同的量測方式,我們計算職責的數量」 取自: Clean Code (p.152) CH1...

鐵人賽 Software Development DAY 6

技術 Day 06: 測試驅動開發 (Test Driven Development)

「然而,沒有測試套件,他們就喪失確保『程式修改後是否仍能照預期般工作』的能力,他們沒辦法保證『對系統某部分的修改不會搞爛系統其他部分的程式』。所以他們的程式缺...

鐵人賽 Software Development DAY 5

技術 Day 05: 物件及資料結構、邊界

「物件將它們的資料隱藏在抽象層後方,然後將操縱這些資料的函式暴露在外。資料結構則將資料暴露在外,且未提供有意義的函式」 「它們不僅是對立的,且本質上也是互補的...

鐵人賽 Software Development DAY 4

技術 Day 04: 函式、錯誤處理

「關於函式的首要準則,就是要簡短。第二項準則,就是要比第一項的簡短函式還要更簡短。這是一個我無法證明的主張」 「我曾經寫過令人難受的 3000 行函式怪物,寫...

鐵人賽 Software Development DAY 3

技術 Day 03: 有意義的命名、好的註解、垂直 & 水平編排

「我們是認真嚴肅地看待命名這件事,請您牢記這一點」 取自: Clean Code (p.20) 前言 命名在軟體開發中無處不見,我們除了替: 變數 (V...

鐵人賽 Software Development DAY 2

技術 Day 02: 給全端開發者的 Coding Conventions & Style Guide 補充

「回到我在貝爾實驗室(The Bell Lab)工作的日子。我們有個不嚴謹的發現,採用一致性的縮排風格是降低程式錯誤率的最顯著指標之一。」 「我們原本希望架構...